Border Gateway Protocol (BGP) is the routing protocol of the Internet. It is used to exchange routing information between Autonomous Systems (AS) and routing traffic across the Internet. Forwarding BGP updates within an AS introduces a couple of challenges. First, BGP requires a BGP router to add its own AS number (ASN) entry to the AS_PATH attribute when forwarding BGP route updates to another AS. The AS_Path attribute identifies the ASes through which an UPDATE message has passed and lists in reverse order the ASes traversed by a prefix, with the last AS placed at the beginning of the list. The primary purpose of AS_PATH is to provide loop-prevention during inter-AS routing. Second, to avoid routing loops, BGP drops a route if a BGP router sees its own ASN in the AS_PATH list. Thus, when forwarding a BGP route advertisement through the routers within an AS, each BGP edge router will add its own ASN to the AS_PATH list. But the next hop BGP router, which is in the same AS, sees its own ASN in the AS_PATH list, assumes that a loop has occurred and drops the route. Although this can be overcome by redistributing all BGP routes into an interior gateway protocol (IGP), and not using BGP, the large number of routes advertised by BGP can cause IGP to crash. To avoid this an internal BGP (iBGP) is used to forward route advertisements received from an external BGP router through the internal network. With iBGP, a router within an AS does not exchange routing updates to another iBGP router. The ASN is added and routes are advertised only when they are being sent to a BGP router in another autonomous system, i.e. to an eBGP router. However, because routing updates learned are not advertised to other iBGP peers to prevent loops, route reachability must be achieved by using a full-mesh topology between all the iBGP peers. This means that every device within an AS is logically connected to every other device through a peering relationship.
Deploying iBGP full-mesh topology can cause scalability issues in large networks. To exchange routing updates with all the other BGP routers in the full-mesh, each peering router uses up network resources. Additionally, to add new iBGP router network engineers must establish a connection to every other BGP router within the AS. This requires configuration changes on backbone routers, which results in network downtime. These problems may be avoided through the use of a Route Reflector (RR).
An RR is an iBGP feature that eliminates the need for a BGP full-mesh topology and allows iBGP to scale in large networks. The RR mechanism allows a iBGP router to act as a RR that advertises (reflects) the routes it learns from one iBGP router to other iBGP peers within the AS.
The internal peers that connect to an RR are classified as RR client peers. An RR along with its client peers form a cluster. Each cluster can have multiple RRs which helps avoid a single point of failure and achieve redundancy. It is also possible to have multiple RRs within an AS where each RR is a non-client peer to another RR.
RRs are critical components in large network functionality to support high scale. Large complex topologies require a large number of RRs to run the network and provide some protection from outage events. Traditionally, RRs were deployed in pairs to support some failover functions however dual-failures would result in service outages. To improve the resiliency more RRs can be deployed but this comes with a higher cost and functional challenge that drives up scale throughout the topology. Additionally, in virtual environment servers are taken out of service for planned maintenance frequently resulting in ongoing states where there is only one RR functioning. This exposes the network to more frequents service interruptions.